The present invention relates to computer communication networks, and more particularly to networks having clients and servers. In such a network, a server is typically a process that has access to some resource, such as a database, shared files, printers, or the Internet. A client is typically a process that can contact the server to request access to the resource. For instance, a client can send a message to a server requesting information from the resource. The server then retrieves that information from the resource, performs any necessary processing, and transmits it to the client. The server can also facilitate transfers of information from the client to the resource by accepting information from the client and sending it to the resource. The client, server, and resource(s) may, but need not, be hosted on physically separate platforms.
A communication network as described above can include a number of servers and a number of clients. To request access to a resource, a particular client may be able to contact any of several servers, any or all of which may provide access to that resource.
Often, when a client accesses the resource through a particular server, the server will store state information relating to the client's connection to the particular server. In this case, having the same client contact a second server for a subsequent request may be undesirable because the second server would not have stored the same state information. In some cases, the lack of state information may affect the second server's ability to process or comply with the client's request.
For instance, if the client establishes a secure communication session with a first server, the first server may store a key required for decoding encrypted messages from the client. If the client then contacted a second server, the second server would not have the same key stored, and thus would not be able to decrypt the client's messages. Since only the first server would be able to decrypt the client's encrypted messages, the client should contact only the first server for subsequent requests, at least while the encryption arrangement is still valid.
The idea that a client should direct subsequent requests to the same server, as described above, is the notion of affinity between a client and server. When affinity has been established between a client and server, the server is then known as the client's elected server. Establishing affinity may require storing affinity information so that the client can determine which server to contact for its subsequent requests. This affinity information can include any information relating to the affinity relationship, such as the identity of the elected server, and can be stored in many locations, such as in a file system or an HTTP cookie.
Methods for managing affinity currently known in the art include schemes in which the affinity relationship exists only for the duration of a session, where a session is a lasting connection between a client and a server, which can consist of the exchange of a number of packets. For instance, a client and server may negotiate a session key when establishing an encrypted SSL session, concurrently establishing affinity between the client and server. Thereafter, the client avoids connecting with another server while the session key is valid because doing so would require a costly and unnecessary renegotiation of a second session key. When the original session key and associated affinity expires, which may happen after a predetermined time period, the client is then free to contact another server because renegotiation of a new session key is no longer unnecessary.
Aside from the expiration of a session, affinity relationships can also be broken by such events as client reset, failure of a communication link between the client and elected server, or failure of the elected server, among others.
There is need in the art for a method for managing affinity that provides for the restoration of a previously established affinity when the client has for some reason lost its affinity information while the elected server is still willing to act as an elected server. Such a method would be valuable because it would enable clients to reestablish affinity without loss of state information and would further avoid costly recreation of state information.
Current methods for managing affinity can also often result in sub-optimal load balancing across servers. For instance, an affinity scheme may cause all requests from a particular IP address to be directed towards a particular server. However, a group of clients using port address translation may all appear to have the same IP address. In this case, assigning affinity based on IP address can result in an exceptionally high load on a particular server because that server may be assigned to handle traffic from an IP address that has associated with it requests from a group of clients, rather than just one client. Because methods for managing affinity currently known in the art can result in such unbalanced loading of servers, the art can benefit from an affinity managing scheme that effectively balances the load across servers.